aarch64-softfloat: forbid enabling the neon target feature #135160
Conversation
|
r? @Noratrieb rustbot has assigned @Noratrieb. Use |
rustbot
added
S-waiting-on-review
|
This change looks good to me. On the off chance that a kernel user comes up in the near future, they can use the "be careful" approach you mentioned in #134375 (comment). |
|
Yeah, separately building some crates with |
traviscross
added
T-lang
Will that mean something like |
|
I don't think we should allow target features to do that (I was imagining target modifiers would introduce a new flag for overriding ABI-relevant target features, if there's any good use for that), and so far there was no proposal to allow overriding target modifiers on a per-function basis. The text you quoted referred to |
RalfJung
force-pushed
the
aarch64-softfloat-not-neon
branch
from
2bd82d7 to
bdf1e78
Compare
|
I'm happy with this as long as we acknowledge that this is a temporary workaround until LLVM starts handling ABI independently of target features. |
|
Fully agreed, the ideal end state is that we can use the FPU while sticking to a softfloat ABI (what clang and GCC do for |
RalfJung
added
the
relnotes
Noratrieb
added
S-waiting-on-team
|
Was this discussed by T-lang prior to be approved? I assume yes since I see the release notes label, correct? cc @traviscross probably knows |
|
We are waiting for t-lang approval, hence the "I-lang-nominated" and "S-waiting-on-team" labels. |
tmandry
removed
the
T-compiler
|
@rfcbot fcp merge |
|
Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. |
rfcbot
added
proposed-final-comment-period
|
I would want relnotes to include a workaround (unfortunately, sounds like it's moving code into another crate and doing some cross-target shenanigans that cargo may not support). Since this is hitting an LLVM limitation it sounds like there's not much else we can do. But if there is any significant breakage we should revisit this decision. |
RalfJung
force-pushed
the
aarch64-softfloat-not-neon
branch
from
bdf1e78 to
36f233c
Compare
|
|
|
@rfcbot fcp cancel |
bors
added
the
S-waiting-on-author
|
rust-lang/stdarch#1803 needs to land in stdarch first, and then propagate to this repo. (rust-lang/stdarch#1655 strikes again.) |
bump stdarch This should unblock rust-lang#135160. r? `@Amanieu`
Rollup merge of rust-lang#141337 - RalfJung:stdarch, r=Amanieu bump stdarch This should unblock rust-lang#135160. r? `@Amanieu`
|
☔ The latest upstream changes (presumably #141379) made this pull request unmergeable. Please resolve the merge conflicts. |
RalfJung
force-pushed
the
aarch64-softfloat-not-neon
branch
from
ceef31c to
3c020e5
Compare
|
@bors try |
… r=<try> aarch64-softfloat: forbid enabling the neon target feature This fixes rust-lang#134375 in a rather crude way, by making [the example](https://godbolt.org/z/r56xWo8nT) not build any more on aarch64-unknown-none-softfloat. That is a breaking change since the "neon" aarch64 target feature is stable, but this is justified as a soundness fix. Note that it's not "neon" which is problematic but "fp-armv8"; however, the two are tied together by rustc. `-Ctarget-feature=+neon` still works, it just causes a warning (but one that we do hope to make a hard error eventually). Only `#[target_feature="neon"]` becomes a hard error with this PR. More work on the LLVM side will be needed before we can let people use neon without impacting the ABI of float values (and, in particular, the ABI used by automatically inserted calls to libm functions, e.g. for int-to-float casts, which rustc has no control over). Nominating for `@rust-lang/lang` since it is a breaking change. As-is this PR doesn't have a warning cycle; the hope is that the aarch64-unknown-none-softfloat target is sufficiently niche that there's no huge fallout and we can easily revert if it causes trouble. A warning cycle could be added but would need some dedicated rather hacky check in the target_feature attribute handling logic. try-job: dist-various-1
|
☀️ Try build successful - checks-actions |
|
@bors r=Noratrieb rollup=iffy |
bors
added
S-waiting-on-bors
|
@bors p=4 |
|
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 912981a (parent) -> e7f4317 (this PR) Test differencesShow 282 test diffsStage 1
Stage 2
Additionally, 279 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard e7f4317ea0e891296163414c6f681ccec976abc3 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (e7f4317): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary -0.7%, secondary 2.6%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 777.508s -> 778.581s (0.14%) |
bump stdarch This should unblock rust-lang#135160. r? `@Amanieu`
This fixes #134375 in a rather crude way, by making the example not build any more on aarch64-unknown-none-softfloat. That is a breaking change since the "neon" aarch64 target feature is stable, but this is justified as a soundness fix. Note that it's not "neon" which is problematic but "fp-armv8"; however, the two are tied together by rustc.
-Ctarget-feature=+neonstill works, it just causes a warning (but one that we do hope to make a hard error eventually). Only#[target_feature="neon"]becomes a hard error with this PR.More work on the LLVM side will be needed before we can let people use neon without impacting the ABI of float values (and, in particular, the ABI used by automatically inserted calls to libm functions, e.g. for int-to-float casts, which rustc has no control over).
Nominating for @rust-lang/lang since it is a breaking change. As-is this PR doesn't have a warning cycle; the hope is that the aarch64-unknown-none-softfloat target is sufficiently niche that there's no huge fallout and we can easily revert if it causes trouble. A warning cycle could be added but would need some dedicated rather hacky check in the target_feature attribute handling logic.
try-job: dist-various-1